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(57) Abstract: The invention regards a method 
of creating a transaction related record and 
includes communicating (26) selection data to a 
remote user terminal (24) wherein the selection 
data provides a user with an option to select 
payment for the transaction from one of a credit 
card (30), a telephone, and a bank account (32). 
The method monitors which particular account 
type the user selects and receives account data 
associated with the particular account. Thereafter, 
account data and an account type identifiers 
that identifies the account type selected by the 
user is included in a transaction record (28). 
The transaction record is then communicating to 
transaction processing equipment. The invention 
extends to transaction processing system and to 
merchant network equipment (2) and transaction 
processing equipment. 
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METHOD OF CREATING A TRANSACTION RELATED RECORD 

FIELD OF THE INVENTION 

[0001]The present invention relates generally to the field of financial 
transaction records and, more specifically, to method of, and merchant network 
equipment for, creating a transaction related record. The invention also relates 
to a method of, and transaction processing equipment for, processing a 
transaction between a purchaser and a merchant. 

BACKGROUND OF THE INVENTION 

[0002] Merchants concluding transactions with purchasers via the 
Internet typically verify financial instrument information prior to finalizing the 
transaction. For example, if the purchaser wishes to pay using a credit card, 
the merchant typically obtains details of the credit card from the purchaser and 
verifies the transaction via a credit card gateway prior to finalizing the 
transaction. Likewise, if the purchaser wishes to pay using funds in a bank 
account, the merchant typically first verifies the transaction via an Automated 
Clearing House Network (ACH) prior to finalizing the transaction. It will thus be 
appreciated that the merchant is required to communicate different standard 
records for verification dependent on the type of financial instrument that the 
user selects, and the merchant is also required to deal with a different facility. 
For the purposes of this specification, the application of the invention to the 
Internet should be predominantly, but not exclusively, borne in mind. 

SUMMARY OF THE INVENTION 

[0003] According to the invention, there is provided a method of creating a 
transaction related record, the method including: 

communicating selection data to a remote user terminal, the 
selection data providing a user with an option to select payment for a 
transaction from one of a credit card, a telephone, and a bank account; 



WO 03/065277 



PCT/US03/03016 



monitoring which particular account type the user selects; 

receiving account data associated with the particular account; and 

including the account data in a transaction record for communication 
to transaction processing equipment, the transaction record including an 
account type identifier that identifies the account type selected by the user. 

[0004] Further in accordance with the invention, there is provided merchant 
network equipment, which includes: 

a communication module to 

communicate selection data to a plurality remote user terminals 
via a communication network, the selection data providing a user with an 
option to select payment for a transaction from one of a credit card, a 
telephone, and a bank account, and 

receive account data associated with a particular account type 
which the user selects; and 

a processor module to include the account data-in a transaction 
record for communication to centralized transaction processing equipment, the 
transaction record including an account type identifier that identifies the 
account type selected by the user. 

[0005] Still further in accordance with the invention, there is provided a 
method of processing a transaction between a merchant and a purchaser, the 
method including: 

receiving a transaction record from merchant network equipment; 

identifying from the transaction record an account type selected from 
the group including credit card, a telephone and a bank, account; 

creating a standard transaction record from the transaction record 
when the account type is a credit card account and a bank account; and 

communicating the standard transaction record to a credit card 
gateway when the selected account type is a credit card account and to an 
automatic clearing house (ACH) when the selected account type is a bank 
account. 

[0006] Still further in accordance with the invention, there is provided 
transaction processing equipment for processing a transaction between a 
merchant and a purchaser, the processing equipment including: 
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a merchant communication module to receive a transaction record 
from merchant network equipment; 
a processor module to 

identify from the transaction record an account type selected from 
the group including credit card, a telephone and a bank, account and, 

create a standard transaction record from the transaction record 
when the account type is a credit card account and a bank account; and 
a financial service communication module to communicate the 
standard transaction record to a credit card gateway when the selected 
account type is a credit card account and to an automatic clearing house 
network (ACH) when the selected account type is a bank account. 

[0007] The invention extends to a transaction processing system, which 
includes: 

merchant network equipment including: 
a user communication module to 

communicate selection data to a plurality remote user 
terminals via a communication network, the selection data providing a 
purchaser with an option to select payment for a transaction from one of a 
credit card, a telephone, and a bank account, and 

receive account data associated with a particular account 
type which the purchaser selects; and 

a processor module to include the account data in a transaction 
record which includes an account type identifier that identifies the account type 
selected by the user; and 

transaction processing equipment connected to the merchant 
network equipment via a communication network, the transaction processing 
equipment including: 

a merchant communication module to receive a transaction 
record from the merchant network equipment; 
a processor module to 

identify from the transaction record an account type 
selected by the purchaser and, 

create a standard transaction record from the transaction 
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record when the account type is a credit card account and a bank account; and 

a financial service communication module to communicate the 
standard transaction record to a credit card gateway when the selected 
account type is a credit card account and to an automatic clearing house 
network (ACH) when the selected account type is a bank account. 

[0008] Other features of the present invention will be apparent from the 
accompanying drawings and from the detailed description that follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] The present invention is illustrated by way of example and not 
limitation in the figures of the accompanying drawings, in which: 

Figure 1 shows a schematic block diagram of a prior art system for 
processing a transaction concluded via the Internet; 

Figure 2 shows a schematic representation of a system, in accordance 
with the invention, for processing a transaction via the Internet; 

Figure 3 shows a schematic block diagram of transaction processing 
equipment, in accordance to the invention; 

Figure 4 shows a schematic diagram of the interaction between various 
participants in the transaction processing system; 

Figures 5 to 8 show schematic representations of exemplary screen 
layouts provided by merchant network equipment, also in accordance with the 
invention, to a user terminal; 

Figure 9 shows a schematic operational flow diagram of the transaction 
processing equipment; 

Figure 10 shows a schematic block diagram of a validation system for 
validating a transaction requested by a purchaser to be billed to a telephone 
account; 

Figure 1 1 shows a schematic flow diagram of the system of Figure 9; 

Figures 12 to 14 show more detail schematic diagrams of certain steps 
of the flow diagram of Figure 1 1 ; 

Figure 1 5 shows a schematic operational diagram of the transaction 
processing equipment during a billing cycle for a particular transaction; 
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Figure 16 shows a schematic flow diagram of a billing process using a 
hybrid transaction record; and 

Figure 17 shows a schematic block diagram of computer equipment that 
may be used to implement the user terminal, merchant network equipment, 
and/or the transaction processing equipment. 

DETAILED DESCRIPTION 

[0010] In the following description, for purposes of explanation, numerous 
specific details are set forth in order to provide a thorough understanding of the 
present invention. It will be evident, however, to one skilled in the art that the 
present invention may be practiced without these specific details. 

[0011] Referring to the drawings, reference numeral 20 generally indicates a 
prior art system for processing a transaction between a merchant 22 and a 
user or purchaser using a user terminal 24 (typically a personal computer or 
the like) via the Internet 26. When the user purchases goods and/or services 
via the Internet 26, the user is usually prompted to enter credit card or bank 
account details into the user terminal 24, which are then communicated via the 
Internet 26 to the merchant 22. Dependent upon the mode of payment 
selected, the merchant 22 then communicates a standard bank account 
authorization record, as commonly used in the industry, to a bank validation 
gateway 28, or communicates a standard credit card authorization record to a 
credit card validation gateway 30. Usually, the merchant 22 first validates or 
checks whether or not the transaction can be processed by communicating 
with the bank validation gateway 28 or credit card validation gateway 30 and, if 
so, the merchant 22 may then obtain payment for the transaction via an 
appropriate bank 32. Thus, in the prior art, the merchant 22 is required to 
communicate a standard authorization record, either a standard credit card 
authorization record or a standard bank account authorization record, to a 
validation facility. Different records are thus communicated to different facilities 
dependent upon the particular payment method selected by the user. 

[0012] Referring in particular to Figure 2 of the drawings, reference numeral 
40 generally indicates a transaction processing system, in accordance with the 
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invention. The system 40 includes merchant network equipment 42, also in 
accordance with the invention, provided at different remote merchants 50, and 
transaction processing equipment 44, also in accordance with the invention, 
which is configured to communicate with the merchant network equipment 42 
via communication lines 46. In the embodiment depicted in the drawings, the 
communication lines 46 are shown as dedicated communication lines. 
However, it is to be appreciated that the communication lines 46 may also form 
part of the Internet 26, as shown in broken lines in Figure 2. The merchant 
network equipment 42 is connected via an Internet interface 48, which defines 
a user communication module, to the Internet 26 so that the merchants 50 can, 
via the merchant network equipment 42, offer goods and/or services 
(cumulatively referred to as products) for sale to a variety of purchasers via the 
user terminals 52 connected to the Internet 26. The user terminals 52 may be 
conventional personal computers (PC's) or the like. As described in more 
detail below, a user may select a variety of different payment methods to 
purchase goods via the Internet 26 and the merchant network equipment 42 
then communicates a transaction record which includes an identifier identifying 
the particular type of payment method selected by the user to the transaction 
processing equipment 44. The transaction processing equipment 44 then 
creates a standard transaction record for communication to an appropriate 
validation and/or billing facility. 

[0013] In particular, the transaction processing equipment 44 includes a 
processor module 64 including an application program interface (API) 65 
which, as described in more detail below, extracts the relevant account data 
and account type identifiers from the transaction record received from the 
merchant 50 and creates an appropriate standard record. The standard record 
is then communicated via a financial service communication module 66 (see 
Figure 3) to one of a credit card validation facility 54 (see Figure 2), a 
telephone bill validation facility or system 56, a bank validation facility 58, a 
check clearing facility 60, and a direct billing facility 62. When the transaction 
processing equipment 44 receives a response from the relevant facility 54-62, 
the response is then communicated via the processor module 64 to the 
merchant 50. Accordingly, the processor module 46 may define a single API 
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that receives a single transaction record and creates a standard transaction 
record therefrom for communication to the relevant facility 54-62. 

[0014]The transaction processing equipment 44 may include an automatic 
line number identification (ANI) module 68 (see Figure 3) that automatically 
identifies a subscriber line from which the user terminal 52 accesses the 
Internet 26. As described in more detail below, a telephone number 
associated with the subscriber line is used when the purchaser elects to effect 
payment for a transaction using a telephone account. The transaction 
processing equipment 44 creates one of a plurality of standard records suitable 
for one of. the facilities 54-62 and, accordingly, includes a standard record 
creation module 70 which then communicates the standard transaction record 
to the financial service communication module 66 as described above. 
Further, the transaction processing equipment 44 includes a customer 
management system 72 which may function in a conventional fashion. 

[001 5] Referring in particular to Figure 4 of the drawings, reference numeral 
80 generally indicates a further embodiment of a transaction processing 
system in accordance with the invention. The system 80 includes the 
components of the system 40 and, accordingly, like reference numerals have 
been used to indicate the same or similar features unless otherwise indicated. 
In the system 80, a transaction processing facility 82 provides a one-stop 
transaction processing facility which a vendor or merchant 50 can use to 
authorize transactions, effect billing for transactions, and provide collection of 
funds for each transaction billed. 

[001 6] As mentioned above, a purchaser or user typically purchases goods 
and/or services from the merchant 50 using the user terminal 52. The 
merchant 50 using its merchant network equipment 42 communicates data, as 
shown by line 86, to the user terminal 52 that provides the user with an option 
to purchase goods and/or services using a plurality of different account types. 

[001 7] Once the user has selected the particular goods and/or services 
which he or she wishes to purchase (see line 84), the merchant network 
equipment 42 communicates a choice of payment method screen layout 88 
(see Figure 5) for display on the user terminal 52. The screen layout 88 
includes a credit card button 90, a bank account button 92, and a telephone bill 
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button 94. This may also include additional payment options not shown in this 
drawing such as Direct Bill, WebBill or the like. The purchaser may then select 
which particular account type he or she wishes to use to effect payment for the 
purchase and, dependent upon which particular button is activated, a further 
screen layout is provided by the merchant network equipment 42. In particular, 
if the user activates the credit card button 90, a credit card information screen 
layout 96 (see Figure 6) is provided on the user terminal 52. The user then 
selects the particular type of credit card to be used, as shown at 98, and 
thereafter enters both credit card and billing address details as shown at 100. 
If, however, the user activates the bank account button 92 thereby selecting to 
effect payment by the bank account, a bank account detail screen layout 102 
(see Figure 7) is provided on the user terminal 52. The user then enters the 
appropriate data into the fields as shown at 104. 

[0018] If the user wishes to charge the purchase to a telephone account or 
telephone bill, he or she activates the telephone bill button 94 and, in response 
thereto, a telephone detail screen layout 106 (see Figure 8) is provided on the 
user terminal 52. The telephone detailed screen layout 106 requires the user 
to enter his or her telephone number in field 108, as well as a customer code in 
field 110. The telephone number is user entered and is compared to the ANI. 
If the ANI is not captured, then the telephone number is collected here and 
validated for its billing status. However, if the number is deemed billable, then 
the ANI is captured subsequently. The user is then required to confirm the 
telephone number by activating either the "YES" button 1 12 or the "NO" button 
114. If the "NO" button 1 14 is activated, then the user is required to re-enter 
the telephone number in the field 108. If, however, the "YES" button 1 12 is 
activated the information is then communicated to the merchant network 
equipment 42. 

[0019] Prior to finalizing any transaction, the merchant 50 typically requires 
validation of the particular account type that the user has selected to secure 
payment. Accordingly, the merchant 50 communicates a validation request, as 
shown by arrow 116 (see Figure 4) to the transaction processing facility 82. In 
a preferred embodiment, the request is in the form of the transaction record, as 
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herein before described, which includes transaction type identification data as 
well as merchant identification data. 

[0020] The transaction processing facility 82 then, via its transaction 
processing equipment 44, investigates an appropriate facility, e.g., the credit 
card validation facility 54, the phone bill validation facility 56, the bank 
validation facility 58, the check validation facility 60 or the direct bill validation 
facility 62. Accordingly, unlike the prior art, the system 80 allows the merchant 
50 to validate a transaction using a single transaction processing facility 82 
which, in turn, performs the necessary validations. The transaction processing 
equipment 44 then communicates validation data, as shown by arrow 118, to 
the merchant network equipment 42 of the merchant 50. The merchant 
network equipment 42 then communicates an appropriate response to the user 
terminal 52 dependent upon whether or not the transaction has been validated. 
If the transaction has been validated, the transaction is then finalized between 
the merchant 50 and the purchaser and an appropriate communication is then 
forwarded to the transaction processing facility 82 to effect payment for the 
transaction, as described in more detail below. 

[0021] Referring to Figure 9 of the drawings, reference numeral 120 
generally indicates a schematic operational flow diagram of a validation 
process 120 which is carried out by the transaction processing equipment 44. 
The validation process 120 is carried out in real-time and is invoked by the 
merchant 50 using its merchant network equipment 42 via a HTTP request as 
shown at step 122. The processor module 64, which runs the API 65, is 
configured to receive (using its merchant communication module 67) and 
identify a transaction record associated with any one of the account types 
which the user may select, analyzes the transaction record and identify which 
particular account type has been selected (see step 124). The transaction 
record includes an indicator defined by indication data, as shown below, to 
identify the account type chosen by the user: 



Validation Type 


Purpose/Description 


Indicator 


LEC 


Perform LEC Validation 


01 


Cr ditCard 


Perform Credit Card Authorization 


04 
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ACH 



Perform ACH Routing Number Check 



05 



[0022] This information is typically required on all validation requests. 

[0023] When attempting to charge a transaction to a telephone account it is 
important to ensure that the local exchange carrier (LEC) has a billing 
arrangement with the transaction processing facility 82 as described in more 
detail below with reference to Figure 10. 

[0024] An example of an HTTP validation request received by the 
transaction processing equipment 44 is as follows: 



Validation Request Example: 
http://validationurl/servlet?va!type=00&clientid=7000 



[0022] The parameters in the request are typically as follows: 



Parameter 
Key 


Value Type 


Value 
length Max 


Description 


required 


Id 


numeric 


4 


Client ID 


yes 


valtype 


numeric 


2 


Validation Type - LEC, CC, 
ACH 


yes 


Pass 


alphanumeric 


30 


Password assigned to client 


no: 


name 


alpha 


30 


Name 


no 


streetl 


alphanumeric 


30 


Street 


no 


streel2 


alphanumeric 


30 


Street 


no 


city 


alpha 


30 


City 


no 


state 


alpha 


2 


State 


no 


zip 


numeric 


5 


Zip 


no 


zip4 


numeric 


4 


ZipPlus4 


no 



[0023] In addition to the above information, the following account type 
dependent parameters must be passed in a validation request. 



LEC Specific Validation Request: 

[0024] In addition to the required parameters outlined above, the following 
parameters should be used when performing a LEC validation request. 
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Parameter 
Kev 


Value Type 


Value 
length Max 


D scription 


required 


ani 


numeric 


10 


Number to be validated, required 
unless btn is present 


hoc V"vtn 

yes or uui 


btn 


numeric 


10 


Number to be validated, required 
unless ani is present 


yes or ani 


dni 


numeric 


10 




no 


clientid 


numeric 


4 


Ebillit assigned customer id 


yes 



[0025] An example of an HTTP validation request when the purchaser has 
selected a telephone account to pay for his or her purchases is as follows: 



LEC Request Example: 
http://validationurl/servlet?valtype=01& 

clientid=7000&ani=4083624000 

[0026] An embodiment of a specific validation procedure, in which the 
subscriber line associated with the telephone account is validated, is described 
further on with reference to Figures 10-14. 

[0027] The API 65 parses the transaction record an extracts the relevant 
identification data to determine the specific account type that the user has 
selected (see step 122). Once the account type has been identified (for 
example, 01 being for a telephone account, 04 being for a credit card account, 
and 05 being for an account requiring ACH type transaction), the API 65 
extracts the telephone number associated with the subscriber line (ANI) unless 
a billing telephone number (BTN) is present in the record received from the 
merchant network equipment 42. The validation procedure is then carried out 
as shown at step 126 (see Figure 9). The transaction is then either approved 
or declined as shown in step 128 and an appropriate response is returned to 
the browser initiating the HTTP request at the merchant network equipment 42. 
It is however to be appreciated that the validation inquiry using HTTP protocol, 
may be effected by a user activating an appropriate hyper-link on a display 
screen of the user terminal 52 so that the validation process may take place via 
a direct communication 130 (see Figure 4) between the user terminal 52 and 
the transaction processing equipment 44 at the transaction processing facility 
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82. Typically, the response of the validation request is communicated to the 
merchant network equipment 42 and, accordingly as shown at step 132, the 
transaction processing equipment 44 may communicate a response to the 
browser of the merchant network equipment 42. The merchant network 
equipment 42 may then interpret or react upon the approval or declining of the 
transaction as the merchant 50 deems fit. 

[0028] If the API 65 detects that the user has in fact selected a credit card 
type account for payment for the transaction, in which the transaction indicator 
data includes the indicator 04, the API 65 parses the transaction record 
received and creates a standard credit card inquiry record which is 
communicated to a conventional credit card gateway or validation facility 54. 
As in the case of the telephone account, the request received from the 
merchant network equipment 42 is also in the form of a HTTP request which 
includes identification data indicating that the request is for a credit card 
validation. The data including in the HTTP request is typically as follows: 

Credit Card Specific Validation Request: 

[0025] In addition to the required parameters outlined above, the following 
parameters should be used when performing a Credit Card validation request. 



Parameter 
Key 


Value Type 


Value 
length Max 


Description 


required 


txtype 


alpha 


1 


Type of transaction to process 
A=Authorization, S=Sale, D=Delayed 
Capture, C=Credit, V=Void 


yes 


tender 


alpha 


1 


Indicates type of tender being used 
C=Credit Card 


yes 


merchant 


Alphanumeric 


4 


Merchant account to use for transaction 
Variable length alpha-numeric Merchant 
Account Number assigned by XYZ 


yes 


account 


numeric 


16 


Consumers account number 
Credit card number 


yes 


expdate 


date 


4 


Cardholder's expiration date 
MMYY 4-digit expiration date 


yes 


amt 


dollar 


10 


Transaction amount 

A decimal point separates dollars from 

cents 


yes 
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origid 


alphanumeric 


20 


used only when submitting D, C, or V 
transaction types 

Alpha-numeric number provided on initial 
transaction 


yes 


street 


alphanumeric 


50 


Used to perform AVS. 
Consumers street number 


yes 


zip 


numeric 


5 


Used to perform AVS. 
Consumers zip code. 


yes 


subid 


alphanumeric 


25 


Subscriber ID 

Account Number or ID assigned to 
subscriber being charged 


no 


key 


alphanumeric 


25 


Unique Key 

Used for mapping to a particular 
subscriber account. Used when XYZ 
stores subscriber payment instrument 


no 



[0026] An example of a credit card validation request from the merchant is 
as follows: 



Credit Card Request Example: ^"J 

"https://validationurl/servlet?id=XXXX&valtype=04&trxtype=A" + 
-&tender=C&merchant=xxxx&account=5105105105105100&expdate=0402" + 
"&amount=1 .00&street=1 23 Street&zip=951 21 &subid=101 345&key=txyz001" 

[0027] The details that are included in this record are provided by the user 
(see the display screen layout 96 in Figure 6). Accordingly, the API 65 
converts an HTTP request, including indication data indicating the particular 
account type with which the request is associated, to a standard transaction 
record suitable for communication to the credit card validation facility 54 (see 
also Figure 2). 

[0028] In addition to the required parameters set out above when the 
purchaser selects to pay for transaction using a bank account type, the 
validation request communicated by the merchant network equipment 42 to the 
transaction processing equipment 44 includes details of an ABA/routing 
number as well as a bank account number. Typically the record is as follows: 

ACH Specific Validation Request: 
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[0029] In addition to the required parameters set out above, the following 
parameters should be used when performing a ACH validation request: 



Parameter 
Key 


Value Type 


Value 
length Max 


Description 


require 
d 


routing 


numeric 


9 


9 digit ABA/Routing Number 


Yes 


account 


numeric 


25 


Bank Account Number 


Yes 



equipment 42 is as follows: 



Credit Card Request Example: 



M https://validationurl/servlet?id=XXXX&valtype=05&routing=00 
00000000&account=1 23456789" 



[0031] As in the cases above, the API 65 identifies the particular account 
type and creates a standard transaction record for communication to the ACH 
facility 58 (see Figure 2). 

[0032]Thus, in summary, the user has the option to select one of a plurality 
of different account types to effect payment for a transaction. Once the user 
has selected the particular account type then the merchant network equipment 
42 communicates a transaction record to the transaction processing equipment 
44 which then performs the particular validation request. Once a validation 
response has been received from the credit card validation facility 54, the 
phone bill validation facility 56, or the ACH facility 58, an appropriate 
transaction record is then communicated using HTTP techniques to the 
merchant network equipment 42. As discussed in more detail below, a storage 
flag may be set to store account information associated with the user at the 
transaction processing facility 44 so that, in future transactions, an account 
identifier need only be sent to the transaction processing facility 44 thereby to 
enhance security of the account information. 

[0033] When responding to a validation request, the transaction processing 
equipment 44 typically includes a transaction record including the following 
fields: 



Field 



Purpose/Description 



Field Values 
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response 



Response code returned to show 
success or failure of a transaction. 



See Validation Response below 



[0034] An example of a validation response communicated by the 
transaction processing equipment 44 to the merchant network equipment is as 
follows: 



Validation Response Example: 



response 



000 - transaction validated 



[0035] The following parameters are typically returned for each LEC specific 
(telephone account) validation request: 

LEC Specific Validation Response: 

[0036] In addition to the parameters outlined above, the following are 
exemplary parameters returned for each LEC specific validation request: 



Parameter 
Key 


Value Type 


Value length 
Max 


Description 


required 


response 


numeric 


3 


Response code. 


yes 


newarecode 


numeric 


10 


Full phone number with new areacode 


no 


permissivedat 
e 


numeric 


8 


when new area code will be effective, 
format is yyyymmdd 


no 



[0037]The following is an example of the response to the merchant 50. 



LEC Response Example: 



response|newareacode|permdate 



000|5103624000|20011231 



Credit Card Specific Validation Response: 

[0038] In addition to the parameters outlined above, the following are 
exemplary parameters returned for each Credit Card specific validation 
request: 
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Field 


Purpose/Description 


Field Values 


Indicator 


Transaction Id 


Transaction Id/Number assigned by 
processor to credit card transaction 


Alpha-numeric 
number 


transid= 


Transaction Result 


Result Code of transaction 


bee ldi oaten 
Processing Spec 


result= 


Response Message 


Response message returned with 
transaction 


oee tbi uatcn 
Processing Spec 


respmsg= 


Authorization Code 


i ransacuons approveo uy me uanK 
will receive an authorization code 


A Inhst.ni inriDrir 
r\l JJi Id -1 lUIIIcl IL« 

number 


authcode= 


AVS Address 
Response 


Match, No Match, Info not available 
provided by bank 


Y, N t X 


avsaddr= 


AVS Zip Response 


Match, No Match, Info not available 
provided by bank 


Y,N,X 


avszip= 



[0039] An example of the response to the merchant 50 is as follows: 



Credit Card Response Example: 
tranid|result|respmsg|authcode|avsaddr|Y = 
1234ABCDE|000|Approved|zz5678tq|Y|Y 

ACH Specific Validation Response: 

[0040] in addition to the parameters outlined above the following are 
exemplary parameters returned for each ACH specific validation request: 



Table 1 



Field 


Pu rpose/Descri ption 


Field Values 


Indicator 


Transaction Result 


Result Code of transaction 


See EBI Batch 
Processing Spec 


result= 



Credit Card Response Example: 

response | respmsg 
______ _ _ _ 



[0041] Additionally, if the transaction is approved and the storage or 
originator flag is set, the purchaser account information is assigned a key 
which is sent back with the response. The account information is securely 
stored at the transaction processing facility 44. 

[0042] As shown that step 138 (see Figure 9), if the transaction is not 
approved then an appropriate response is returned to the merchant 50 (see 
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line 140 and step 132). If, however, the transaction is approved, the 
transaction processing equipment 44, if instructed to do so via the storage flag, 
may store account data associated with the particular account type selected by 
the user. In particular, the transaction validation request generated by the 
merchant network equipment 42 includes a subscriber or user identification 
(Subid) and a unique key for mapping stored account data to the specific user, 
(see credit card specific validation request above). When the Subid and Key 
are present in the transaction record (see step 142) account data is stored (see 
step 144) at the transaction processing facility 82. If, however, the Subid and 
Key values are not provided, the transaction processing equipment 44 
assumes that the account data is not to be stored and proceeds directly to step 
132 as shown by arrow 146. The storage of the account data allows future 
transactions to be processed without communication of confidential account 
data but merely communication of the Subid and Key thereby providing 
enhanced security when transacting using the system 80. 

[0043] Returning to Figure 4 of the drawings, once the transaction between 
the merchant 50 and the purchaser has been concluded, typically after a 
successful authorization or validation event as described above, a charge is 
then billed to the particular account type which the user or purchaser has 
selected. However, unlike the prior art systems 20 in which a merchant or 
vendor then communicates with multiple facilities as shown in Figure 1, the 
merchant 50 then via the merchant network equipment 42 communicates a 
single transaction or billing record to the transaction processing facility 82 
which, in turn, creates an appropriate billing record for billing to the appropriate 
facility. Accordingly, the merchant 50 via its merchant network equipment 44 
need communicate only with a single transaction processing facility 82 via its 
API 65. In order to process the billing, a comprehensive or all-in-one billing 
record is communicated to the transaction processing equipment 44. 

[0044] An example of the all-in-one billing record which may be provided at 
the merchant or at the transaction processing facility 82. When direct 
communication 1 30 occurs and the customer management system is hosted at 
the transaction processing facility 82, then the billing cycles will be initiated at 
the transaction processing facility as follows: 
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All-in-One Billing Record 

[0045] After the successful authorization event, the charge will be billed to 
the consumer's payment of choice. Instead of interfacing with multiple formats 
and gateways, an all-in-one billing record allows the Merchant 50 to interface 
with one processing facility in a single record. 

[0046] This file may be client provided or hosted at the transaction 
processing facility. If direct communication 130 occurs and the customer 
management system is hosted at the transaction processing facility, then the 
billing cycles will be initiated at the transaction processing facility 82. 



Colum 

n ' 


Field 

Purpose/Description 


Field Values 


REQ? 


1 


Value 


Transaction value with 
01=LEC billing 
02=Direct Billing 
03=Web Billing 
04=Credit Card Processing 
05=ACH/Check 


Y 


2 


Date 


YYMMDD Format, date at start of transaction or 
billing date 


Y 


3 


Billing or Refund 
record Indicator (LEC 
or Direct) 


1 -character text field indicator 

B=BiIling 

R=Refund 


Y 


4 


Amount 


6-digit $$$$cc charge for the billing or refund record 


Y 


5 


Subscriber Identifier 


Account Number or ID assigned to subscriber being 
charged 


Y 


6 


Subscriber Street 


Street Address of subscriber 


O 


7 


Subscriber Zip 


Zip code of subscriber 


O 


8 


Unique Key 


Unique Key used for mapping to a particular 
subscriber account. Used when XYZ stores 
subscriber payment instrument 


O 


9 


Client ID 


4 Digit Client ID number assigned by XYZ 


Y 


10 


Record Id 


Unique 10 character alphanumeric id assigned by 
Client to record. Used to reconcile submitted 
records. 


O 
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In a direct billing scenario, billing data is processed by a billing system, 
and the output is to a physical paper invoice that is sent directly to the 
consumers billing address of record. In a web billing scenario, billing data is 
processed by a billing system, the output is to an electronic (or web-based) 
invoice. Notification of the bill is sent via email and the consumer who then 
accesses and pays the bill via a standard web browser with a credit card, bank 
account, check or the like. 

In an ACH/Check billing scenario, billing data is processed by a billing 
system and the output is to a standard file format that is electronically 
transmitted through the Automated Clearing House Network. This transaction 
will either deduct from or credit to the consumers bank account for the amount 
specified within the sent transaction. 

[0047] Additionally the following information is provided for each payment 
type. 



LEC 


11 


ANI 


Origination Number 


Y 


12 


Billing Telephone 
Number (BTN) 


Billing Telephone Number 


Y 


13 


DNIS or 

Terminating 

Number 


Call record Terminating Number 


O 


14 


Type 


3 Digit Rate Plan (Position 1 = 1-Flat, 2-Metered) 
(Position 2-3 = unique rates) 


O 


15 


Start Time 


HHMMSS Format 


O 


16 


Duration 


Actual M Off-Hook M time (MMMMSS format) 


O 


17 


Description Code 
(LEC or Direct) 


5 character alpha-numeric description code zero (0) filled 


Y 


CREDIT CARD 


18 


Card Number 


Credit Card Number 


Opt* 


19 


Expiration Date 


Card Expiration Date (MMYY format) 


Opt* 


20 


Credit Card 
Transaction Type 


A=Authorization 
S=Sale 

D=Delayed Capture 

C=Credit 

V=Void 


Y 



19 



WO 03/065277 



PCT/US03/03016 



21 


Process AVS 


Y=Yes 
N=No 


Y 


22 


Transaction# 


Unique alpha-numeric transaction number 

Note: Required when submitting transaction types (field 

17) D, C, orV 


O 


23 


Merchant Account 


Variable length alpha-numeric Merchant Account number 
assigned by EBI 


Y 


ACH/ CHECK 


24 


Subscriber Name 


First & Last Name of subscriber 


Y 


25 


Bank Routing 
Number 


Routing/ABA number at the individual or companies 
bank 


Opt* 


26 


Bank Account 
Number 


Account number at the individual or companies bank that 
is to be debited or credited 


Opt*. 


27 


Check Number 


Check Number 


O 


28 


Account Type 


C=Checking 
S=Savings 


Opt* 



[0048] If the billing record is to go to the telephone bill, then the record 
follows the process set out in Figure 16 and ends up on the telephone bill of 
the purchaser. 

[0049] If the request is to be billed via Credit Card or directly to the bank 
account and the Opt* indicators are set, then the process takes the key to 
identify the account information in the database at the facility 82. After that, 
the records are sent to the appropriate gateway for inclusion on the bill page. 

[0050] The all-in-one billing record defines a hybrid record in that, 
dependent upon its field values (which define a record type identifier), it may be 
associated with a plurality of different account types that are to be billed. An 
example of the different account types that may be billed is shown above. In 
particular, when the record includes a "01" field value then an account at a LEC 
is to be billed, a "02" field value then direct billing is to be carried out, "03" field 
value then web billing is to be effected, "04" then credit card processing is to be 
carried out, and "05" then ACH/check processing is to be carried out. It is to be 
appreciated that further field values may be included in other embodiments. 
Thus, unlike the prior art systems 20 that communicate with different facilities 
for each different account type using different standard record types, the 
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transaction processing facility 82 allows the merchant 50 to communicate a 
single record to a single facility which then processes the transaction. 

[0051] When the transaction is billed to the particular account type selected 
by the user, the transaction processing facility 82 may, via the credit card 
gateway 54, in a conventional fashion debit the appropriate credit card account 
at the bank 32, as shown by lines 150 and 152 in Figure 4. The bank 32 would 
then send an appropriate credit card statement to the user, as shown by line 
154 who, in response thereto, is obliged to settle the account as shown by line 
156. The transaction processing facility 82 pays the merchant 50 as shown by 
line 158 an amount equal to the transaction amount less a fee or commission, 
and the transaction processing facility 82 receives payment for the transaction 
in the full amount from the bank 32 as shown by lines 160 and 162. 

[0052] If, however, the user selects to pay for the transaction using a 
telephone account type, the transaction processing facility 82 bills the 
transaction directly into a telephone account, as shown by arrow 164, at a local 
telephone company 166. The telephone company 166, in return, sends a bill 
or telephone account 168 to the user which includes all transactions conducted 
by the user using the system 80 for any given period and, in response thereto, 
the user is required to settle the account with the telephone company 166 as 
shown by line 170. The telephone company 166, in turn, is responsible for 
paying the transaction processing facility 82 the full amount of the particular 
transaction or transactions as shown by line 172 and the transaction 
processing facility 82 then pays the merchant 50, as shown by line 158, an 
amount equal to the purchase price of the goods and/or services purchased 
less a particular commission or fee. In particular, the transaction processing 
equipment 44, when billing a transaction, follows a billing process 173 as 
shown in Figure 15. Initially, the transaction processing equipment 44, as 
shown at step 174, receives an all-in-one billing file from the merchant network 
equipment 42. Each record within the file is then parsed to determine whether 
it is a telephone billing record, a credit card billing record, or an ACH billing 
record as shown at step 176. Dependent upon the account type to which the 
transaction is to be billed, the process 173 proceeds along one of the three 
legs. 
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[0053] If the billing record is associated with a telephone account, an ANI 
validation procedure 178 (substantially the same as the procedure shown at 
step 126 in Figure 9) is preformed. Thereafter, if the transaction is approved 
as shown at step 180, the transaction processing equipment 44 creates a 
conventional EMI transaction file and posts the file to the particular LEG for 
processing as shown at step 182. 

[0054] If the billing record is associated with a credit card, the transaction 
processing equipment 44 processes the transaction, as shown at step 184 and 
inspects the billing record to determine if account identification data identified 
by the SUBID and KEY value is provided (see step 186). If no SUBID and KEY 
value is provided in the transaction or billing record, the transaction processing 
equipment 44 uses the information from the billing record of the all-in-one file 
to process the transaction (see step 188) and, thereafter, performs real time 
credit card transaction with a payment gateway partner in a conventional 
fashion (see step 190). If, however, the SUBID and KEY values are provided, 
the transaction processing equipment 44 retrieves transaction information or 
account information from its database and uses this information to process the 
transaction (see step 192). Accordingly, the system 80 provides security 
enhancements in that the merchant network equipment 42 in any subsequent 
transactions need not provide confidential account data. 

[0055] If, however, the client has selected to effect payment for the 
transaction using a bank account, the transaction processing equipment 44 
then processes the billing record so that it is suitable to be sent to an ACH 
system (see step 194) and, in a similar fashion to that described above, 
determines whether or not a SUBID and KEY value is provided in the billing 
record as shown in step 195. If no SUBID and KEY value is provided, the 
transaction processing equipment 44 then uses account information provided 
in the all-in-one billing record (see step 196) and thereafter creates an ACH 
transaction file which is posted to an ACH processor partner (see step 198). If, 
however, a SUBID and KEY value is provided, then the transaction processing 
equipment 44 retrieves confidential account information from its database (see 
step 197) and processes the transaction as shown at step 198. The ACH 
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transaction file may then, in a conventional fashion, be communicated to a 
secure FTP site. 

[0056] Referring in particular to Figure 10 of the drawings, reference 
numeral 200 generally indicates a schematic block diagram of and exemplary 
validation module provided at the phone bill validation facility (which is typically 
provided at the transaction processing facility 82). The module 200 includes an 
application program interface (API) 201 that is connected to the transaction 
processing equipment 44. In addition, it is however to be appreciated that the 
API 201 may be connected to a variety of different hosts or clients which 
require validation of a subscriber line via which the remote terminals 52 carry 
out transactions for goods and/or services via the Internet 26. 

[0057] The transaction processing equipment 40 communicates the 
telephone number of the subscriber line to the module 200 which then 
processes the information and provides a validation status, e.g. a code 
indicating a valid billable number or a code indicating that the line number is 
not a valid billable number (unbillable or non-billable). In particular, a plurality of 
codes associated with various statuses of the subscriber line is communicated 
to the transaction processing equipment 44 as described in more detail below. 

[0058] The module 200 includes hardware and software to implement the 
invention. In particular, the module 200 includes a comparator module 218, a 
threshold database 220, an OFFNET database 222, an ONNET database 224, 
a competitive local exchange carrier (CLEC) database 226, a 42 BLOCK 
database 228, a block and cancel database 230, an unbilled and/or unpaid bills 
database 232, line identification database (LIDB) short term cache 234, a 
validity check module 236, a regional account office (RAO) database 238, an 
operating company number (OCN) database 240, an ONNET database 242, 
an address verification database 244, customer account record exchange 
(CARE) results database 246, an ANI watch database 248, and an NPA 
(Numbering Plan Area) exchange database 250. It is to be appreciated that, in 
less sophisticated embodiments of the invention, all of the above databases 
need not be included. However, for enhanced accuracy, all of the above 
databases are preferably included. Further databases may also be included 
further to increase the reliability of the validation process. 
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[0059] In addition to any one or more of the above databases, the module 
200 is in communication via a conventional communication channel with an 
offsite or, in some embodiments, on-site line identification database (LIDB) 
host 252. The LIDB host 252 may include a line number portability (LNP) 
database. Typically, the LNP database may front end access to a plurality of 
industry standard LIDBs (e.g. 13 different LIDBs). The LNP database may 
however be a separate database. As described in more detail below, the 
module 200 communicates the subscriber line number to the LIDB host 252 
which, in turn, communicates reference subscriber data in the form of industry 
standard LIDB codes back to the module 200 for processing. The module 200 
then processes the LIDB codes to provide the merchant 84 with validation data 
relating to the purchase or transaction based on subscriber line. Unlike 
conventional LIDB applications which use a LIDB to make decisions regarding 
destination subscriber lines or call completion decisions, e.g. decisions for 
calling cards, collect and third party toll services or the like, the module 200 is 
used to identify telephone numbers of originating subscriber lines. 

[0060] Broadly, the module 200 includes a processor module 201 that 
includes the various databases 220 to 232 as well as the comparator module 
218 and the validity check module 236, and an interrogation module 256 for 
interrogating the LIDB host 252. One or more servers with associated 
databases may define the aforementioned modules. Further, in the example 
illustrated, the LIDB host 252 is shown as a single database but may comprise 
many different LIDB databases maintained by various LECs and, accordingly, 
may be located at various different geographic locations. 

[0061] Referring in particular to Figures 1 1 to 14 of the drawings, various 
flow charts describing the method of operation of the module 200 are shown. 

[0062] In Figure 11 of the drawings, reference numeral 203 generally 
indicates a validation process carried out by the module 200. The customer 
management system 72 (see Figure 3) sends the transaction or billing record 
to the module 200 (as shown at step 204). The module 200, when it receives 
the validation request, has its processor module 202 first check (see block 206) 
if all the information required for validation has been furnished by the merchant 
network equipment 42 and, if not, the request is returned to the merchant 50 as 
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shown at step 207. If, however, all the information required by the module 200 
is present in the record, the record is then parsed and the billing telephone 
number (BTN) is extracted from the record and formatted into a validation 
request as shown at step 208. Thereafter, as described more detail in Figures 
12 to 14, the module 200 performs various checks during which the subscriber 
line is validated (see step 209). If the BTN progresses to a LIDB interrogation 
step (as described in more detail below with reference to steps 264 to 286 in 
Figure 12), the request is then reformatted into a LIDB request to obtain LIDB 
response information (see step 210). The LIDB database 211 is then 
interrogated and the LIDB response is received and parsed for relevant 
information whereafter it is reformatted into a BTN validation request as shown 
at step 212. Thereafter, and as described in more detail below with reference 
to Figures 12 and 14, the processor module 202 performs further validation 
checks (see step 213 in Figure 1 1 and steps 296 to 338 in Figures 12 and 14). 
Once the request has been investigated, the various databases have been 
interrogated, and the results retrieved therefrom processed, the processor 
module 202 then translates the validation response into an appropriate 
response that is communicated to the transaction processing equipment 44 for 
communication to the merchant 50 (see step 214). The CMS 72 then updates 
purchase data, and creates an account for the user as shown in step 132. 
Thereafter, the API 201 communicates a display screen to the electronic 
terminal 52 that thanks the user for ordering the good and/or services. 
Typically, each transaction defines a billing that is recorded at the merchant 50 
and, together with other billing events, is communicated to the transaction 
processing facility 82 at the end of a billing cycle (see step 218). 

[0063] As described above, the transaction processing equipment 44 
initiates a request to the module 200 to validate a transaction between the 
vendor and the purchaser to be included in a telephone bill associated with the 
subscriber line. As shown at step 260 (see Figure 12), the module 200 first 
checks to see if the BTN number is present in the request from the transaction 
processing equipment 44 and, if no number is present, a return code 121 is 
generated and communicated to the transaction processing equipment 44 as 
shown at step 262. The code 121 indicates that the module 200 is unable to 
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process the request. If, however, the number is present in the request, the 
module 200 then checks if the line number captured (hereinafter also referred 
to as the ANI) by the ANI module 68 (see Figure 3), and the BTN entered on 
the display screen 106 (see Figure 8) match, as shown at step 264 (see also 
the comparator module 218 in Figure 10). If, however, the ANI and the BTN do 
not match, then the processor module 202 generates a code to indicate that 
the caller and the owner of the line number are not the same person (e.g. the 
user enters his or her BTN in the display screen 106 and uses an electronic 
terminal connected to a different subscriber line and is thus calling from a 
different ANI) and the relevant modified code is then returned to the transaction 
processing equipment 44. 

[0064] If the ANI and the BTN do match, the processor module 202 
interrogates the threshold database 220 (see step 268) to ascertain whether or 
not the line number has reached its threshold (e.g., a predefined client 
threshold parameter such as an account expenditure threshold). If the line 
number has reached its threshold, the processor module 202 then generates a 
code, as shown at step 270, which is then communicated to the transaction 
processing equipment 44 to indicate that the line number may not be granted 
service. In other words, the subscriber account cannot be billed for the goods 
and/or services requested by the user from the merchant 84. 

[0065] If the threshold has not been reached, the module 200 then 
interrogates its OFFNET database 222 (see step 271) to check if the industry 
standard NPA/NXX and operating company number (OCN) of the subscriber 
line is present in the OFFNET database 222. The OFFNET database 222 
includes NPA /NXX and OCN combinations of operating companies with which 
the proprietor or user of the module 200 does not have billing and collections 
agreements to bill into the Telco's bill page associated with the subscriber line. 
Accordingly, the transaction processing facility 82 is unable to include a charge 
in the account associated with the subscriber line on behalf of the merchant 50 
for the transaction. 

[0066] If the line number is in the OFFNET database 222, then the 
processor module 202 generates a plurality of codes (see step 272) and 
communicates these codes to the transaction processing equipment 44. The 
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codes indicate that the NPA/NXX and OCN for the particular line number are 
not billable and, accordingly, charges for goods and/or services requested by 
the user cannot be included in a monthly telephone account by the module 
200. The codes provide an indication to the transaction processing equipment 
44 why the subscriber line is not billable or deliverable. If the subscriber line 
number is not included in the OFFNET database 222, a check is conducted to 
see whether or not the subscriber line number is included in the ONNET 
database 224. This check is however optional in the embodiment depicted in 
the drawings, but may be mandatory if the module 200 does not include the 
OFFNET database 222. 

[0067] Thereafter, as shown in step 278, the processor module 202 checks 
to see if the line number is found in a known CLEC table in the CLEC database 
226. CLEC numbers are those line numbers that are known to have ported to 
a CLEC and, accordingly, the proprietor of the module 200 is thus unable to 
route these line numbers to the correct billing entities. If the line number is 
found in the CLEC database 226, then the processor module 202 generates a 
code (see step 276) that is communicated to the transaction processing 
equipment 44. The code indicates that the BTN provided by the user is not 
billable for the CLEC and the module 200 can thus not charge the transaction 
to the subscriber account associated with the subscriber line. 

[0068] If the line number is not found in the CLEC database 226, then the 
module 200 checks to see if the subscriber of the subscriber line has 
requested a 4250 billing block as shown at step 278. In particular, the 
processor module 202 interrogates the 42 BLOCK database 228 and, if the 
number is located in the database 228, which indicates that monthly recurring 
charges (4250) charges are prevented from being billed to that line number, 
the processor module 202 generates a code (see step 280) which is 
communicated to the transaction processing equipment 44 to indicate that 
billing to the particular subscriber line has been blocked. 

[0069] If, however, the subscriber line has not been blocked, the module 
200 then checks at step 282 if the line number is located in the block and 
cancel database 230 and, if so, the processor module 202 generates a plurality 
of codes which are then communicated to the vendor as shown at step 284. 
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The block and cancel database 230 includes requests from owners of 
subscriber lines, agencies, businesses, or the like that a service be canceled or 
blocked from further billing. Thereafter, the module 200 interrogates the 
unbilled and/or unpaid bills database 232, as shown at step 286, to check if 
there is a history of any unpaid bills and/or unbillable bills associated with the 
subscriber line. Unbillable bills relate to those subscriber line numbers where 
previous attempts have been made to bill charges to the subscriber account 
associated with the line number, and which have been returned as unbillable. 
If the processor module 202 locates the line number in the unbillable and/or 
unpaid bills database 232 then, as shown at step 288, a code is generated and 
communicated to the transaction processing equipment 44 to indicate that the 
line number was previously found to be unbillable and is still considered to be 
unbillable. 

[0070] The process described above conducts a preliminary investigation 
into the subscriber line number or ANI/BTN to provide an initial indication of 
whether or not the ANI/BTN corresponds with a billable subscriber line. Once 
the initial investigation has been conducted, the module 200 then uses the ANI 
to obtain reference subscriber line data in the form of LIDB codes from one or 
more industry standard databases in the form of the LIDB host or database 
252. 

[0071] As shown at step 290, if the ANI is not found in the LIDB database 
252, the module 200 cannot provide any validation data to the transaction 
processing equipment 44 on this subscriber line and an appropriate code is 
then communicated to the transaction processing equipment 44 as shown at 
step 292. 

[0072] Once the LIDB database or host 252 has been interrogated, it 
returns industry standard LIDB codes and line number portability (LNP) data to 
the module 200 as shown in step 294 (see Figure 13). The LIDB codes are 
then mapped or translated by the processor module 202 into modified 
validation codes that provide relevant validation information to the transaction 
processing equipment 44. The same modified validation code can be 
generated from a plurality of different LIDB codes. Once the LIDB information 
codes have been returned to the processor module 202, the LIDB codes, 
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including OCN and RAO response codes, are fed into the validity check 
module 236 (see Figure 10). 

[0073] As mentioned above, the LIDB host 252 may also provide LNP data 
to the module 200. The LNP data is used to identify subscriber line numbers 
that have ported to a CLEC. If a subscriber line has been ported to a CLEC, 
the billing ONNET status of the CLEC is verified in the CLEC database 226. 
The LNP identifies the facilities based CLECs which are CLECs that have been 
assigned all the line numbers for an NPA/NXX in a specific geographic territory. 
This type of CLEC would be in control of the cable, dial tone and billing 
envelope for that number. Typically, the LNP cannot be used to identify CLEC 
sellers that have resold the subscriber line under their brand, but still lease the 
cable and tone from an incumbent local exchange carrier (ILEC). Accordingly, 
the transaction processing facility 82 may be unable to process transaction 
data onto a bill page or telephone account of the CLEC reseller bill page. In 
order to identify reseller CLECs, the module 200 compares RAO and OCN 
information, returned from the LIDB host 252, to data in the ONNET database 
224. The OCN is the local Telco that owns the subscriber line number and the 
RAO is the office of the Telco that is responsible from a billing standpoint for 
the subscriber line number. 

[0074] If the validity check module 236 determines that the response codes 
are invalid, the module 200 generates a plurality of modified codes (see step 
298) which are communicated to the requestor or transaction processing 
equipment 44 to indicate that the mapping of the LIDB codes to the modified 
codes concluded that the line is an unbillable subscriber line. 

[0075] If the validity check module 236 confirms the validity of the LIDB 
codes and, in the event of the line number being a billable line number, the 
processor module 202 then checks the RAO database 238 to ascertain 
whether or not the RAO is billable, as shown at step 300. If the RAO is not 
billable, then the processor module 202 generates and communicates a return 
code (see step 302) to indicate to the transaction processing equipment 44 that 
the line number belongs to a CLEC that is not billable by the module 200. 

[0076] In a similar fashion, at step 304 the processor module 210 checks to 
see if the OCN returned from the LIDB host 252 corresponds with a known 
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CLEC or if the OCN corresponds with an OFFNET OCN and is therefore also 
unbillable. If the line number corresponds to an OCN that is not billable, a 
return code is generated by the processor module 210 and communicated to 
the transaction processing equipment 44 (see step 306). 

[0077] If the subscriber line number has passed the RAO and OCN checks 
and, accordingly, it appears that the number is billable, the processor module 
210 then checks to see if a new NPA /NXX and OCN combination for this line 
number is guidable to the correct local Telco for billing (see step 308). If the 
line number is not guidable, then the module 200 generates a code at step 310 
that is communicated to the transaction processing equipment 44 to indicate 
that, even though the line number is billable, the transaction processing facility 
82 is unable to guide the billing information to the new Telco for billing. 
Accordingly, the telephone number is in fact non-billable insofar as the 
transaction processing facility 82 is concerned and a decline status is therefore 
communicated to the transaction processing equipment 44. 

[0078] The abovementioned steps are carried out to ascertain whether or 
not the subscriber line can be billed for the goods and/or services requested. 
However, to enhance the accuracy or reliability of the module 200, further 
checks or verification are conducted as described below. 

[0079] In the event that the subscriber line number has passed or complied 
with the abovementioned checks, and has thus not yet been rejected, the 
module 200 performs address verification procedures at step 312. The module 
200 then interrogates an address verification database 244 to compare the 
address or location data (e.g. a ZIP code) supplied by the user via a display 
screen on the terminal 52 with reference address data as shown at step 312. 
If, however, the address supplied by the user does not match with the address 
in the verification database 244 or, the addresses are not within a predefined 
range or area, the processor module 202, as shown at step 314, generates a 
plurality of codes that are then communicated to the transaction processing 
equipment 44 to indicate the level of likelihood that the caller (ANI) and the 
account owner are the same person. 

[0080] During the address verification step 312, the module 200 
interrogates a customer account record exchange (CARE) database (which 
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can be an on-site database which is regularly updated), to provide enhanced 
reliability. In particular, the CARE database or information site is typically one 
or more industry standard offsite databases that allow consumers to select or 
change their long distance service provider. Local Telcos forward specific 
customer information to the LEC associated with the subscriber. The 
information communicated typically includes a new phone number, billing 
address, installation date, the person or organization responsible for the 
account, or the like. 

[0081] As shown at step 316, the module 200 interrogates the CARE 
database or information site and CARE data is then loaded into CLEC and new 
line databases to perform certain fraud and billing checks. The CARE 
information investigation occurs after a successful validation event. Once the 
module 200 has validated the subscriber line, the subscriber line number data 
is sent to a CARE database provider hosting the CARE database 246 to obtain 
the BNA and age of the account. The information is typically returned within 48 
hours and then processed. Care records that are returned without BNA and 
CLEC ACCOUNT codes are inserted into the CLEC database 226 for future 
reference. Accordingly, if the BTN is presented again at a later date, it will fail 
the CLEC check step (see step 274 in Figure 12). 

[0082]The ANI watch database 248, which includes historical and adjusted 
information, is used by the module 200 to determine if the account has 
previously been adjusted (see step 316). Typically, this step includes 
ascertaining previous requests by the subscriber for credit, obtaining data on 
any written off amounts for charges that were billed to a bill page, or the like. 

[0083] If adjustments have previously been made to the account associated 
with the subscriber line, the processor module 202 generates a plurality of 
codes (see step 318) to indicate to the transaction processing equipment 44 
that the adjustments have been made. If no adjustments have been made, the 
processor module 202 checks to see whether or not the line number has a 
business line indicator as shown at step 320. If the business line indicator is 
active, the module 200 generates a code (see step 322) that is communicated 
to the transaction processing equipment 44 to advise that the line is a business 
line. Thereafter, as shown in step 324, the processor module 202 checks to 
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see if the subscriber line number has been in service for less than about 90 
days and, if so, a return code (see step 326) is generated to advise the 
transaction processing equipment 44 who may then selectively decide whether 
or not to conclude the transaction. A database of new numbers may be 
updated with the new number. 

[0084] Thereafter, the module 200 interrogates the ANI watch database 248 
(see step 328) to ascertain whether or not the area code of the line number 
has been changed or is scheduled to change. This interrogation is typically for 
billing purposes only and is not used to decide upon the validity of the request. 
In this step, the transaction processing equipment 44 requesting the validation 
typically updates the billing file with the new area code number, and the 
processor module 202 generates a code (see step 330) to advise the 
transaction processing equipment 44 of the scheduled change to the area 
code. 

[0085] Once the line number has passed all the aforementioned checks, the 
module 200 then concludes that the subscriber line obtained using ANI 
techniques is in fact a billable line and, accordingly, the transaction may be 
charged directly to the account of the subscriber. Accordingly, the module 200 
then generates a code (see step 334) that is communicated to the transaction 
processing equipment 44. This code defines an approved status following both 
a billable line number enquiry as well as several fraud checks which are carried 
out by the fraud control module 332. If the line number has passed the 
abovementioned checks and the return code is generated, the process 
terminates at step 336. Thus, step 336 defines the end of the process during 
which the various checks have been conducted on the subscriber line to 
assess whether or not it is a billable subscriber line that charges may be billed 
to. Step 338 defines the last step to which the process jumps when, at any 
point during the abovementioned process, the line number is found not to be 
billable (e.g., a creditworthy decision was requested by the transaction 
processing equipment 44) and the inquiry is accordingly terminated and the 
relevant code is communicated to the transaction processing equipment 44. 

[0086] The abovementioned steps are typically executed in real time. 
However, information sources that do not allow checks on the line number in 
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real time may be are carried out subsequently on the line number. Typically, 
once the real time evaluation is carried out and the return code is 
communicated to the transaction processing equipment 44, and the vendor 
and purchaser proceed with the transaction, transaction data is then 
periodically returned to the module 200 by the transaction processing 
equipment 44 for a pre-billing validation check or actual billing. During actual 
billing the module 200 accesses an account folder of the subscriber line at the 
Telco and inserts the charges due to the transaction processing equipment 44 
into the telephone account. As shown at step 340, line numbers are sent to 
the CARE database 246 to determine if the BNA is available at the local Telco. 
If the folder or telephone account is not available, the local Telco typically 
sends the BNA and codes as to why the number is unavailable to the 
transaction processing facility 44. If the BNA is found in the CARE database 
246, the processor module 202 then checks to see whether or not the account 
was created within the last 90 days as shown at step 342. If the account was 
not created within the last 90 days, then the business indicator is checked as 
shown at step 344 and the process ends as previously shown at step 346. If, 
however, the number was found in the CARE database 246, the account was 
created within the last 90 days, or has an active business indicator then the 
module 200 generates the appropriate codes that are communicated to 
transaction processing equipment 44 and the process terminates as shown at 
step 348. 

[0087] Referring in particular to Figure 16 of the drawings, in certain 
embodiments the transaction processing facility 82 processes all transactions 
during the cycle at the end of a bill cycle. Reference numeral 350 generally 
indicates an example of a telephone account billing process in which the 
merchant 50 communicates a billing transaction file in a all-in-one or hybrid 
format to the facility 82 (see step 352 in Figure 16). Each event or transaction 
in the transaction file includes an indicator or identification data to identify the 
particular account that it is related to, e.g. a telephone account, a credit card 
account, a bank account, or the like. The transaction processing system 44 of 
the facility 82 then receives the billing request file as shown at step 354, 
whereafter the request file is parsed, as shown at step 356, to identify only 
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those transactions to billed to telephone accounts. The request file is also 
parsed by the processor module 64 to check whether or not all the required 
information is present in the file (see step 358). If not, a code is appended to 
the record as show at step 360. If all the information is present in the file, the 
process then proceeds to step 362 where the telephone account validation 
steps 208-214, as described above, are executed. Once the validation 
procedure has been completed, the BTN billing response is formatted into all- 
one-one format response with a response code appended to the end of each 
record and, the records are then returned to the CMS 72 (see step 366). 

[0088] At the same time, transactions or billing events which have been 
validated as billable and thus capable of being included in the relevant 
telephone account, are translated into an electronic message interface (EMI) 
format appropriate for the Telco with which the telephone account is 
associated (see step 366). The EMI formatted file is then transferred to the 
Telco for billing as shown in step 368 whereafter the Telco call places each 
billing event on telephone account associated with the subscriber line(see step 
370). Typically, the Telco returns any records that can not be billed to the 
telephone account or that have already been billed and credited, or written off 
because of non payment to the transaction processing facility 82 as shown at 
step 372. The records received by the facility 82 are in the EMI format and the 
facility 82 translates the record to an appropriate return record including a 
reason code appended to the record, as shown at step 372, whereafter record 
is returned to the CMS 72. 

[0089] Figure 17 shows a diagrammatic representation of machine in the 
exemplary form of a computer system 400 within which a set of instructions, for 
causing the machine to perform any one of the methodologies discussed 
above, may be executed. In alternative embodiments, the machine may 
comprise a network router, a network switch, a network bridge, a web 
appliance or any machine capable of executing a sequence of instructions that 
specify actions to be taken by that machine. 

[0090]The computer system 400 includes a processor 402, a main memory 
404 and a static memory 406, which communicate with each other via a bus 
408. The computer system 400 may further include a video display unit 410 
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(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The 
computer system 400 also includes an alphanumeric input device 412 (e.g. a 
keyboard), a cursor control device 414 (e.g. a mouse), a disk drive unit 416, a 
signal generation device 418 (e.g. a speaker) and a network interface device 
420. 

[0091] The disk drive unit 416 includes a machine-readable medium 422 on 
which is stored a set of instructions (i.e., software) 424 embodying any one, or 
all, of the methodologies described above. The software 424 is also shown to 
reside, completely or at least partially, within the main memory 404 and/or 
within the processor 402. The software 424 may further be transmitted or 
received via the network interface device 420. For the purposes of this 
specification, the term " machine-readable medium" shall be taken to include 
any medium which is capable of storing or encoding a sequence of instructions 
for execution by the machine and that cause the machine to perform any one 
of the methodologies of the present invention. The term "machine-readable 
medium" shall accordingly be taken to included, but not be limited to, solid- 
state memories, optical and magnetic disks, and carrier wave signals. 

[0092]Thus, a system and method, including their various components, 
have been described. Although the present invention has been described with 
reference to specific exemplary embodiments, it will be evident that various 
modifications and changes may be made to these embodiments without 
departing from the broader spirit and scope of the invention. Accordingly, the 
specification and drawings are to be regarded in an illustrative rather than a 
restrictive sense. 
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CLAIMS 

What is claimed is: 

1. A method of creating a transaction related record, the method including: 

communicating selection data to a remote user terminal, the selection 
data providing a user with an option to select payment for a transaction 
from one of a credit card, a telephone, and a bank account; 

monitoring which particular account type the user selects; 

receiving account data associated with the particular account; and 

including the account data in a transaction record for communication to 
transaction processing equipment, the transaction record including an 
account type identifier that identifies the account type selected by the user. 

2. The method of Claim 1 , in which the transaction record is a string 
communicated to the transaction processing equipment using HyperText 
Transfer Protocol (HTTP). 

3. The method of Claim 1, which includes communicating the transaction 
record to the transaction processing equipment to perform at least one of 
validating the transaction and effecting payment for the transaction using 
the selected account type. 

4. The method of Claim 3, which includes providing merchant identification 
data in the transaction record and validating the transaction in real-time. 

5. The method of Claim 4, in which the communicating of the selection data to 
the remote user terminal is via the Internet. 

6. The method of Claim 1 , which includes providing a storage indicator in the 
transaction record which requests the transaction processing equipment to 
store the account data for use in at least one future transaction. 



36 



WO 03/065277 PCT/US03/03016 



7. The method of Claim 6, which includes communicating the storage indicator 
to the transaction processing facility in the future transaction thereby to 
avoid subsequent communication of confidential account data. 

8. A computer program product including a medium readable by a computer, 
the medium carrying instructions which, when executed cause the computer 
to: 

communicate selection data to a remote user terminal, the selection 
data providing a user with an option to select payment for a transaction 
from one of a credit card, a telephone, and a bank account; 

monitoring which particular account type the user selects; 

receive account data associated with the particular account; and 

include the account data in a transaction record for communication to 
transaction processing equipment, the transaction record including an 
account type identifier that identifies the account type selected by the user. 

9. Merchant network equipment, which includes: 

a communication module to 

communicate selection data to a plurality remote user terminals 
via a communication network, the selection data providing a user with an 
option to select payment for a transaction from one of a credit card, a 
telephone, and a bank account, and 

receive account data associated with a particular account type 
which the user selects; and 

a processor module to include the account data in a transaction record 
for communication to centralized transaction processing equipment, the 
transaction record including an account type identifier that identifies the 
account type selected by the user. 

10. The merchant network equipment of Claim 9, in which the processor 
module creates the transaction record in the form of a string communicated 
to the transaction processing equipment using HyperText Transfer Protocol 



37 



WO 03/065277 PCT/US03/03016 

(HTTP). 

11. The merchant network equipment of Claim 10, in which the transaction 
record is communicated to the transaction processing equipment to perform 
at least one of validating the transaction and effecting payment for the 
transaction using the selected account type. 

12. The merchant network equipment of Claim 1 1 , in which the transaction 
record includes merchant identification data in the transaction record and 
the transaction is validated in real-time. 

13. The merchant network equipment of Claim 9, in which the communication 
module is configured to communicate via the Internet. 

14. The merchant network equipment of Claim 9, which provides a storage 
indicator in the transaction record which requests the transaction 
processing equipment to store the account data for use in at least one 
future transaction. 

15. The merchant network equipment Claim 14, which includes communicating 
the storage indicator to the transaction processing facility in the future 
transaction thereby to avoid subsequent communication of confidential 
account data. 

16. A method of processing a transaction between a merchant and a 
purchaser, the method including: 

receiving a transaction record from merchant network equipment; 

identifying from the transaction record an account type selected from the 
group including credit card, a telephone and a bank, account; 

creating a standard transaction record from the transaction record when 
the account type is a credit card account and a bank account; and 

communicating the standard transaction record to a credit card gateway 
when the selected account type is a credit card account and to a bank 
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validation gateway when the selected account type is a bank account. 

17. The method of Claim 16, which includes investigating a subscriber line 
validation system when the selected account type is a telephone account, 
the subscriber line validation system being operable to indicate if charges 
for the transaction can be included in the telephone account. 

18. The method of Claim 16, in which the standard transaction record is 
communicated to one of the credit card gateway and the bank validation 
gateway to perform at least one of approving the transaction and effecting 
payment for the transaction using the selected account type. 

19. The method of Claim 16, which includes communicating transaction 
approval information to the merchant network equipment so that the 
transaction is validated in real-time. 

20. The method of Claim 16, in which the transaction record includes merchant 
identification data to identify a merchant communicating the transaction 
record to the transaction processing equipment. 

21. The method of Claim 16, which includes storing account data and an 
account identifier at transaction processing equipment when the transaction 
record includes a storage indicator, the transaction processing equipment 
being operable to identify and retrieve the account data using the account 
identifier when processing at least one future transaction. 

22. A computer program product including a medium readable by a computer, 
the medium carrying instructions which, when executed cause the computer 
to: 

receive a transaction record from merchant network equipment; 
identify from the transaction record an account type selected from the 
group including credit card, a telephone and a bank, account; 

create a standard transaction record from the transaction record when 
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the account type is a credit card account and a bank account; and 

communicate the standard transaction record to a credit card gateway 
when the selected account type is a credit card account and to an 
automatic clearing house network (ACH) when the selected account type is 
a bank account. 

23. Transaction processing equipment for processing a transaction between a 
merchant and a purchaser, the processing equipment including: 

a merchant communication module to receive a transaction record from 
merchant network equipment; 

a'processor module to 

identifying from the transaction record an account type selected 
from the group including credit card, a telephone and a bank, account and, 
create a standard transaction record from the transaction record 
when the account type is a credit card account and a bank account; and 

a financial service communication module to communicate the standard 
transaction record to a credit card gateway when the selected account type 
is a credit card account and to an automatic clearing house network (ACH) 
when the selected account type is a bank account. 

24. The transaction processing equipment of Claim 23, which investigates a 
subscriber line validation system when the selected account type is a 
telephone account, the subscriber line validation system being operable to 
indicate if charges for the transaction can be included in the telephone 
account. 

25. The transaction processing equipment of Claim 23, in which the standard 
transaction record is communicated to one of the credit card gateway and 
the bank validation gateway to perform at least one of validating the 
transaction and effecting payment for the transaction using the selected 
account type. 
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26. The transaction processing equipment of Claim 23, which communicates 
transaction approval information to the merchant network equipment. 

27. The transaction processing equipment of Claim 23, in which the transaction 
record includes merchant identification data to identify a merchant 
communicating the transaction record to the transaction processing 
equipment. 

28. The transaction processing equipment of Claim 23, which stores account 
data and an account identifier when the transaction record includes a 
storage indicator, the transaction processing equipment being operable to 
identify and retrieve the account data using the account identifier when 
processing at least one future transaction. 

29. A transaction processing system, which includes: 

merchant network equipment including 
a user communication module to 

communicate selection data to a plurality remote user 
terminals via a communication network, the selection data providing a 
purchaser with an option to select payment for a transaction from one of a 
credit card, a telephone, and a bank account, and 

receive account data associated with a particular account 
type which the purchaser selects; and 

a processor module to include the account data in a transaction 
record which includes an account type identifier that identifies the account 
type selected by the user; and 

transaction processing equipment connected to the merchant network 
equipment via a communication network, the transaction processing 
equipment including: 

a merchant communication module to receive a transaction 
record from the merchant network equipment; 
a processor module to 

identifying from the transaction record an account type 
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selected by the purchaser and, 

create a standard transaction record from the transaction 
record when the account type is a credit card account and a bank account; 
and 

a financial service communication module to communicate the 
standard transaction record to a credit card gateway when the selected 
account type is a credit card account and to an automatic clearing house 
network (ACH) when the selected account type is a bank account. 

30. The system of Claim 29, in which user communication module interfaces 
the merchant network equipment to the Internet and the purchasers 
transact with the merchant via the Internet. 

31. The system of Claim 30, in which the merchant network equipment is a web 
server. 

32. A method of billing a plurality of transactions, the method including: 

receiving a plurality of transaction records from merchant network 
equipment; 

identifying from each transaction record an associated account type 
selected from the group including credit card, a telephone and a bank, account; 
creating a standard transaction record from the transaction record; and 
communicating the standard transaction record to a credit card gateway 
when the selected account type is a credit card account, to an automatic 
clearing house (ACH) network when the selected account type is a bank 
account, and to telephone company when the selected account type is a 
telephone account. 
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purchaser & creates account. 
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Account created & billing event slotted into bill cycle 



Thank You 
For Ordering 



End Of BTN Validation From VALAPI 
Record Translation 
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Client provides EBI with All-ln-One Billing file 
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XYZ System reads each billing 
record in the file and 
determines which billing 
process to invoke by reading the 
transaction value store in the first 
column of each record. 
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Process ANI Validation Process Credit Card transaction 
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for processing. 
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XYZ system 

determines 
whether or hot to 

retrieve the 

transaction 
information by seeing 
if the billing recorded 
includes 2 variables; 
Subscriber Identifier 

(Column 5) & 

Unique Key 

(Column 8) 




If Subscriber Identifier 
(Column 5) & Unique Key 
(Column 8) variables are 
found to be present in the 
billing record, the XYZ 
process uses those to 
variable to lookup the 
payment account 
information for that 
particular subscriber. 
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When bill cycle available for billing, customer management system 
releases billing transaction file in All-ln-One format. 
An indicator in the record signifies a phone billing transaction. 

— ± 
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System receives billing request file 



Request is parsed for information. 
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Append code to record 



Follow Steps 208-216 



At conclusion, BTN billing response is formatted into an All-ln-One 
billing response with response code appended to end of record. 



Records are returned to Customer Management System. 
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At same time, transactions validated as "Billable" 
are translated to EMI format per phone company requirements. 
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EMI formatted file is transferred to Telco for billing. 
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Telco places billing events on individual phone bills. 
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Telco returns any records that cannot be billed, have been 
billed & credited or written-off because of non-payment to facility. 
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Records are received by facility in EMI format. Facility translates record 
to credit card return record with reason code appended to record. 
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Facility returns records to Customer Management System for account update. 



376 



Fig. 16 



WO 03/065277 



PCT/US03/03016 



15/15 



400 



PROCESSOR 



402 



INSTRUCTIONS 




424 



MAIN MEMORY 



404 



INSTRUCTIONS 



424 




NETWORK 
INTERFACE 
DEVICE 




BUS 
408 




VIDEO 
DISPLAY 



410 



ALPHA-NUMERIC 
INPUT DEVICE 



412 



CURSOR CONTROL 
DEVICE 

414 



DRIVE UNIT 416 



MACHINE-READABLE 
MEDIUM 



INSTRUCTIONS 



422 
. 424 



SIGNAL GENERATION 
DEVICE 

418 



Fig. 17 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/USos/03016 



A- CLASSIFICATION OF SUBJECT MATTER 

IPC(7) :G06F 17/60 

US CL : 705/39, 40, 4-2,44, and 45. 
According to International Patent Classification (IPC) or to both national classification and IPC 



FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 
U.S. : 705/39, 40, 42,44, and 45. 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields 
searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



US 5,748,890 A (GOLDBERG et al) 05 May 1998, col. 4, line 46- 
col. 7, line 60, col. 8, line 1-col. 10, line 21. 

US 5,740,427 A (STOLLER) 14 April 1998, col. 5, line 16-col. 8, 
line 65, col. 9, line 7-col. 11, line 61, col. 12, line 1-coL 15, line 
65, col. 16, line 4-col. 23, line 44. 

US 6,330,543 Bl (KEPECS) 11 December 2001, col. 4, line 25-col. 
5, line 65, col. 6, line 1 1-col. 8, line 63, col. 9, line 6-coi. 12, line 
65, col. 13, line 9-col. 17, line 15. 

US 6,247,047 Bl(WOLFF) 12 June 2001, col. 6, line 25-col. 8, line 
64, col. 9, line 16-col. 11, line 60, col. 12, line 1-col. 15, line 21. 



1-32 



1-32 



1-32 



1-28 



| 1 Further documents are listed in the continuation of Box C. | | See patent family annex. 



Special categories of cited documents: 

document defining the general state of the art which is not considered 
to be of particular relevance 

earlier document published on or after the international filing date 

document which may throw donbts on priority claim(s) or which is 
cited to establish the publication date of another citation or other 
special reason (as specified) 

document referring to an oral disclosure, use, exhibition or other 



"X" 



document published prior to the international filing date but later 
than the priority date claimed 



later doc a me ut published after the international filing date or priority 
date and not in conflict with the application but cited to understand 
the principle or theory underlying the invention 

document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive stop 
when the document is taken alone 

document of particular relevance; the claimed invention cannot be 
considered to involve an inventive step when the doc um ent is combined 
with one or more other such documents, such combination being 
obvious to a person skilled in the art 

document member of the same patent family 



Date of the actual completion of the international search 



01 APRIL 2003 



Date of mailing of the international search report 

% 2 APR 2003 



Name and mailing address of the ISA/ US 
Commissioner of Patents and Trademarks 
Box PCT 

Washington, D.C. 20231 
Facsimile No. (70S) S05-32SO 



Authorized officer fi 

HYUNG SOUGH \£j 
Telephone No. (703) 308 0505 



Form PCT/ISA/210 (second sheet) (July 1998)* 



